Computing systems—i.e. devices capable of processing electronic data such as computers, telephones, Personal Digital Assistants (PDA), etc.—communicate with other computing systems by exchanging messages according to a communications protocol that is recognizable by the systems. To enforce security and prevent unwanted messages from entering a system, many computing systems implement security filters that screen messages entering (or, in some cases, exiting) the computing systems.
Filters are also utilized to process messages received by a service. (As used herein, different services may be included in the same process, a different process, the same machine or a different machine.) A filter is a query that returns a value of true or a value of false when tested against an input. One type of system that utilizes filters is a messaging service system that receives messages from various sources and routes those messages to different systems. For example, a financial services system can receive multiple stock quotes and route certain stock quotes to particular subscribers to the service by associating a filter with each subscriber. When a message (i.e. stock quote) is received, the message is compared to filters stored the financial services system. The message is forwarded to a subscriber if a filter associated with that subscriber is satisfied by the message. If, say, John Doe has signed up to receive stock quotes for Microsoft, then a filter associated with John Doe will be satisfied when a message containing a Microsoft quote is received. The Microsoft quote will then be forwarded to John Doe.
Multiple filters stored in a system are usually stored together in a filter table. An inverse query engine receives an input (i.e. a message) and tests that input against each of the filters (i.e. queries) in the filter table. Although the terms “filter table” and “inverse query engine” may be used interchangeably, as used herein a filter table is a data structure containing the filters and the data associated therewith, and an inverse query engine is the logic that uses the filter table to drive the comparison process. Usually, as in the examples used herein, an inverse query engine encompasses a filter table, although that may not always be so since the inverse query engine and the filter table could be stored in separate locations or even be located in separate components.
Frequently, filters are not owned or controlled by a system in which they are stored. A messaging service computer, for example, stores filters that are owned by others. At a basic level, when a subscriber tells a system which message the subscriber will receive, the subscriber has added or modified a filter in the messaging service computer.
This issue can lead to memory management problems for inverse query engine systems such as uncontrolled growth of the filter table, since other computers and users can create and store a virtually unlimited number of filters in a filter table. System efficiency is deteriorated because the inverse query engine must process an enormous amount of filters for each message—many of which are probably out of date.
General computer system processing can also be compromised if the filter table is stored in general memory (i.e. RAM) that can be utilized by other functions in the system. As more and more filters are stored in the filter table, less and less memory is available for other functions in the system. Conversely, if the memory is filled by other functions, then there may not be sufficient memory available for the filter table when it is required.
Another problem is that current inverse query engine systems are not as robust as desired by developers who create and maintain systems to work with the inverse query engine system. If the inverse query engine system does not have an integrated cache or a satisfactory solution for managing its filters, then a burden is placed upon developers of other systems to create their own solutions (e.g. cache creation and management) for maintaining their filters that are stored in the inverse query engine system.
Developers or filter owners may want their filters to remain in an inverse query engine system for limited times only, realizing that their needs will change over time or for security reasons. Some filter owners may also desire that their filters be removed from a system if the filter is not utilized for a certain period of time. The filter owners must then keep track of all other computers that store their filters and devise methods to manage the filters according to their needs, even though the filters are in the possession of other entities.
Accordingly, a more efficient and more robust solution is desirable.